<?php
/**
 * <https://y.st./>
 * Copyright © 2015 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Major remodeling, both on the site and in Minetyst',
	'<{body}>' => <<<END
<p>
	I was finding myself doubting the need for a fork of minetest_game again.
	After all, couldn&apos;t I do a lot of what I want by just adding extra modules? I was thinking that maybe I should hold off on building a new game until I had enough modules to create a game out of them.
	At that point, I could simply remove minetyst_game from my server entirely and fill in a gap or two still left by its absence with new modules for the occasion.
	However, minetest_game simply doesn&apos;t meet my needs.
	It&apos;s a survival-type subgame and I want a subgame more geared toward construction.
	Furthermore, on a technical level, minetest_game aliases some engine-related nodes to other engine-related nodes.
	There&apos;s nothing inherently wrong with that (aside from the fact that many of those nodes should be consolidated to use just one name in the engine), and in fact I do it with one node in my subgame, but once it&apos;s done, there is no going back with the old map.
	Once a map has had two nodes treated as one for a while, it causes changes that are not reversible.
	Furthermore, would there ever be a time when my modules could truly separate from minetest_game without a forking of some sort? I can draw somewhat, but I&apos;ll probably never be able to replace the minetest_game sound effects.
	As a free software user, I have the freedom to fork the software I use, and if it makes me happy and is not disrupting others, I should do so.
</p>
<p>
	Speaking of my minetest_game fork, I need to get going on learning Esperanto.
	I want my node names to be written in that language, so the sooner I can figure out what those node names are the better.
	In Minetest, once you have named a node, you pretty much have three choices.
	You could leave the name as it is.
	In that case, if I had already added English-named nodes, I would have a part English part Esperanto game, and that seems like a mess.
	You could change the name and make an alias.
	If you do that, you need to leave the alias in the code pretty much forever, as the game does not change all the names on the map automatically.
	Rather, it changes the names on the map only in places that get loaded into memory at the time they are loaded.
	Any section of the map that does not get loaded will retain the old names and still need the alias for when those nodes finally do get visited by players.
	If I did this, I would have English embedded in my Esperanto game, and I don&apos;t really want that.
	The last option is to rename the nodes without creating aliases.
	This causes any node on the map that still uses the old name to become an &quot;unknown node&quot;, a gray and pink ugly node that isn&apos;t really good for much, save to act as a place holder in case the node definition is ever restored.
	Seeing as I would be changing an all-English game to an all-Esperanto game, all nodes besides the built-in air would become unknown, ruining everyone&apos;s creations.
	This seems like the worst option of all.
</p>
<p>
	I had been leaving the module names intact for modules that I didn&apos;t make many changes to from minetest_game&apos;s version, but that might not be the best idea.
	If another module depends on a module that I forked, it may think it has what it needs if my module is present when it really does not.
	I think renaming all the modules would be a better idea, and as a bonus, that would allow me to likewise convert those names to Esperanto.
	I also have been thinking about how messed up my version of the default module is.
	It&apos;s really gimmicky, and guests on my server deserve better.
</p>
<p>
	I decided that maybe I should just remove default from the game entirely and just treat the node names used by the engine that are within the <code>default</code> namespace as aliases like the regular map generator aliases.
	That would free me to pretty much do whatever I want with those nodes.
	Originally, I was planning to do something very simple with default.
	I had planned to make a very few of those nodes spawn during map generation very rarely.
	These would be the nodes such as saplings, water, and lava that are involved in their own replication.
	From there, I would find a way to generate all the other default nodes using those nodes.
	I think I should go back to that plan, but call the module whatever the Esperanto word for &quot;antiques&quot; is.
	This time though, the antiques module won&apos;t be self-sustaining.
	I had a very messy setup for generating and regenerating antique nodes, and I think a separate &quot;renew&quot; module would make things cleaner gameplay-wise.
	I could for example set up a water filtration node that when placed next to water nodes will occasionally generate a dirt or sand node that it has &quot;filtered out of the water&quot;.
</p>
<p>
	Last time I had a Minetest server, I tried to build a very long tunnel to a very specific point.
	However, people kept putting in requests that I connect my tunnel to their creations, most of which lied in completely-different directions.
	I never made it to where I wanted to go because I was swamped with requests to tunnel to other places.
	This time, things will be different.
	I have learned from my mistakes and am now better-organized.
	In order to get me to accept a tunnel request, you must go through one of two channels.
	The first option is to pay me with a chest full of a particular node my subgame will have, a node formed by crafting together nine steel blocks.
	That is the equivalent of 2592 iron ingots.
	Even if people are willing to pay (they won&apos;t be), gathering up that much iron for me will slow down the requests significantly, allowing me to actually make progress in the direction I want to go.
	The second option is to convince me that you can type in fluent Esperanto.
	This will allow you to request gratis tunnel entrances, but would in theory mean that once someone learns Esperanto, they could singlehandedly fill my tunnel entrance queue.
	For that reason, if you choose to take the Esperanto option instead of paying me, there will be sever limitations on where I will tunnel to.
	The main tunnel has twelve major veins, so in order to request a tunnel entrance without paying, the nearest planned vein must be completed up to the point that it would need to branch off to reach your requested area.
	That pretty much means that for the first year or so, gratis tunnel entrances will only be available in one direction from the spawn area.
</p>
<p>
	I know I&apos;ve been doing a lot of speaking about Esperanto today, but it&apos;s been on my mind lately.
	I have just a little bit more to say before I put away my virtual pen.
	I plan to begin writing my weblog in Esperanto in an effort to help myself learn the language (I will translate all entries to English for any English-readers).
	Once I know the language well enough, I&apos;ll go back and translate the rest of the website, including past weblog entries.
	I&apos;ll move the current English things I&apos;ve written to <code>/en/</code> and put the new Esperanto work in <code>/eo/</code>.
	Anything that doesn&apos;t need multiple versions such as licenses, $a[CSS], and non-text work will remain outside the language code directories.
	I&apos;ll set up redirects to deal with old $a[URI]s that may still be in circulation.
	for now, the redirects will point to the English versions of pages, as they are the only pages in existence, but once the Esperanto versions are available, they will become the canonical versions of the pages and the redirects will shift to point to those.
	If you have any bookmarks/hyperlinks and are only interested in the English version, update your bookmarks/hyperlinks accordingly.
</p>
<p>
	I fixed the issue with <a href="/en/weblog/2015/03-March/21.xhtml">March 21</a>&apos;s weblog entry, or at least I fixed it enough to get that entry added back to the site.
	The $a[PHP] work is probably done, but there is some $a[CSS] work that still needs doing.
	Now that the entry is back up though, it has fallen significantly on my priority list and I&apos;ll likely not finish it for a long while.
</p>
<p>
	<strong>*Update*:</strong> It appears the Web server is not cooperating with me.
	If &quot;{filename}.xhtml&quot; is missing, Apache is more than happy to serve &quot;{filename}.xhtml.asc&quot; in its place.
	This has been more of a nuisance than a help up until today.
	But now, when I tried to put that to use by creating &quot;{filename}.xhtml.php&quot; files to do some redirecting, I find that Apache refuses to serve the $a[PHP] replacement pages.
	Due to how minimal my site is, that was my only real option for redirecting.
	Instead, I&apos;m going to have to put up ugly pages saying that the page has been moved and offering a hyperlink to the new locations.
	It&apos;s not great, but it&apos;s the best I have right now.
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
END
);
